Information / Description of a new standard

                                S  tandard
                                R  equest
                                I  nformation
                                F  ile

         Copyright (c) 1994,95,96 by Gordian Schuermann & Mirko Mucko

                Current revision  1.02, dated of June 02 1996

                 The latest revision of this document is avail
                      for file request with magic "SRIF"


I  Overview
                Introduction                            0
                Contact person                          0.1
                Description in general                  1
                  Required statements                   1.1
                  Optional statements                   1.2
                  Undefined options                     1.3
                Implementation                          2.0
                Updates to this revision                3.0


0. Introduction
 In common, more and more mailer are about to implement the ability to
 call external request processors. But very soon, we discovered a command
 line cannot handle all the information the mailer has and the ERP needs.

 To transfer the information in a proper and fast way, we designed and
 implemented the S R I F option in the mean it will be a standard soon.

 The structure and idea is protected by copyright law, except these
 circumstances:

        +  you may distrubute, use and implement this structure for free
        +  you have not to pay any value for usage of these methodes
        +  you should note in your documentation the origin of SRIF

0.1 Contact persons
 In case of trouble understanding SRIF, the concept, meaning ot purpose
 of ot, or even have questions concerning the implementation, or if you
 have bug fixes or any other note for us, you may reach us at:

        Mirko Mucko

        e-mail  fidonet   2:2433/920.0
                internet  mirko.mucko@technet.net

        FAX     +49-211-9083026

        snail   Mirko Mucko
                Thomas-Mann-Str. 43
                40470 Duesseldorf
                GERMANY

1. Descritption
 The SRIF name is the only parameter given from the Mailer to the External
 Request Processor. The file is designated as a so called "plain vanilla ASCII"
 file, filled with pre-defined, optional and not-yet defined statemets.

 We discussed the possibility of binary files, and of EMSI-like files, but
 a plain ASCII control file is more flexible and can be read faster by
 various program languages (C, Pascal, Basic, Cobol ect).

 In the SRIF, one command plus parameter is allowed per line, the file
 is unlimited in length, comments are not allowed.

 The SRIF is generated by the Mailer and after the ERP finished its work,
 the Mailer is responsible for erasing the SRIF.

1.1 Required statements
 The following statements are required for the ERP:


       Sysop            <Sysop_Name>
                        This is the name of the remote sysop

       AKA              <Zone:Net/Node[.Point][@Domain]>
                        This is the main aka of the remote system in 4D or
                        5D notation. A zero as point number may be ommited,
                        the domain with "@" is optional

       Baud             <Current LINE rate>
                        This is the effective baud rate, not the fixed DTE rate

       Time             <Time in minutes>
                        This is the time till next event which does not allow
                        file requests. Use -1 if no limits

       RequestList      <File of request list>
                        This is the filename of the list containing requested
                        files.
       ResponseList     <File of response list>
                        This is the filename of the response list.
                        It must not be equal to RequestList. One file per line,
                        including drives/pathes to the file. The first
                        character defines the way the mailer should act after
                        sending that file:

                         =   erase file if sent successfully
                         +   do not erase the file after sent
                         -   erase the file in any case after session

       RemoteStatus     <PROTECTED or UNPROTECTED>
                        Defines whether the session is protected by password
                        or not

       SystemStatus     <LISTED or UNLISTED>
                        Defines whether the remote system is listed in any
                        current nodelist of system.

1.2 Optional statements
 These parameters are already known and defined, but a ERP should run also
 without them:

       SessionProtocoll <e.g. ZAP,ZMO,XMA

       AKA              <Zone:Net/Node[.Point][@Domain]>
                        Additional AKAs. One AKA is required (see REQUIRED
                        section)

       Site             <Site Info>
                         The site info as given e.g. in EMSI handshake

       Location         <Location and/or ZIP>
                         The location info as given e.g. in EMSI handshake

       Phone            <Phone Number>
                         The  phone number info as given e.g. in EMSI handshake

       CallerID         <Phone Number>
                         The phone number as delivered by the PTT. This is
                         only possible in digital networks like ISDN.


       Password         <Session password>
                         On protected sessions, the session password. If
                         no protected session, this parameter must be ommited!

       DTE              <Current DTE rate>
                         The PC<->Modem speed (so call DTE rate)

       PORT             <COM Port from 1 to 8>
                         The FOSSIL Communication Port. The Mailer should
                         leave the fossil "hot" for the Request Processor

       Mailer           <Remote's mailer if EMSI>
                          The Mailer name as defined by FTC

       MailerCode       <Remote's FTSC code>
                          The hex code of the remote mailer as defined by FTC

       SerialNumber     <Remote's serial number if passed>
                         The remote mailer's serial number if transfered

       Version          <Remote's version number if EMSI>
                         The remote mailer's version number if transfered

       Revision         <remote's revision number if EMSI>
                         The remote mailer's revision number if transfered

       SessionType      <may be EMSI, FTSC0001, WAZOO, JANUS, HYDRA or OTHER>
                         The session-type, this may be one of the known
                         session types or "OTHER" if not (yet) defined

       OurAKA           <AKA which has been called for proper response>
                         If the mailer does AKA matching, the AKA of the
                         mailer being called

       TRANX            <Tranx Line as 8 digit hex string>
                         The unix-style time stamp (hexadecimal notation
                         of seconds since 1.1.1980)

1.3 Undefined options
 There may be the need to add new commands / parameters to the SRIF file. If
 so, they may be added, but inform us to keep the documentation "up to date"
 and to share your good ideas with other autors of software for FIDONet.


2.0 Implementation
 SRIF is implemented in these fine products already :

                Mailer                  Request Processor
                ------------------------------------------------------
                McMail                  xOR
                Xenia                   EasyERP
                TMail [*]

  [*] means : SRIF is not completely correct implemented and therefor
              may cause troubles in operation

 Other products will follow soon ! If YOUR product also supports SRIF,
 just drop us a mail and we will include it here.

3.0 Updates to this revision
 To revision 1.02, we added the "CallerID" field within optional parameters
 to make Request Reject possible depending on the delivered phone number.
 This is only possible in ISDN and similar networks and must be supported
 by the mailer AND the fossil.
 Also, section 0.1 (contact person) has been added.